FHIR Servers
A FHIR server stores FHIR resources and exposes them over the standard REST API. That much is common to all of them. What differs — and what decides your choice — is validation, terminology, search performance, security model and operational cost.
What a server is expected to do
| Capability | Meaning |
|---|---|
| CRUD | Create, read, update, delete resources by type and id |
| Search | Standard and custom search parameters, chaining, _include |
| Versioning | Resource history and vread |
| Validation | Check resources against base spec and profiles |
| Terminology | $expand, $validate-code, $lookup against value sets |
| Transactions | Atomic Bundle processing |
| Capability statement | Machine-readable declaration of what is supported |
| Security | Authentication, authorisation, audit logging |
| Subscriptions | Notify clients when matching data changes |
A server that does CRUD but not validation or terminology will hand you those problems in application code instead.
Open-source options
HAPI FHIR JPA Server — the Java reference implementation. The most widely deployed open-source option; complete resource coverage, embeddable, backed by a relational database.
Microsoft FHIR Server for Azure — open-source .NET implementation, runnable self-hosted or as the basis of the managed Azure service.
IBM FHIR Server / LinuxForHealth — Java, strong on conformance and extensibility.
Aidbox (community edition) — Clojure/PostgreSQL, notable for flexible storage and terminology handling.
Blaze — designed for large-scale analytical queries via CQL.
Medplum — TypeScript, developer-oriented, with a batteries-included application layer.
Managed services
- Google Cloud Healthcare API — see GCP health
- Azure Health Data Services — see Azure health
- AWS HealthLake — see AWS health
Managed services remove operational work and add per-request cost, data residency questions and less control over version timing. In jurisdictions with health data localisation requirements, that last point often decides it.
Choosing one
Ask, in this order:
- Data residency and legal constraints. These eliminate options fastest.
- FHIR release support, and how the vendor handles version migration — including whether two releases can run in parallel during an upgrade.
- Profile validation. Will it enforce your implementation guide?
- Terminology. Built-in service, or another system to run?
- Search performance at your expected volume and query shape.
- Security model. SMART on FHIR, OAuth2, consent enforcement, audit.
- Operational fit. Your team's languages, databases and deployment tooling.
Operating a FHIR server
- Never expose it unauthenticated. A default HAPI deployment left open is a recurring incident pattern.
- Log access to the resource level — see ISO 27799.
- Index for your real queries; default indexes rarely match production search patterns.
- Keep a test server with synthetic data so integrators are never testing against real patients.
- Publish your capability statement and profiles — integrators should not have to guess.
Related
- HAPI FHIR
- HL7 FHIR
- Amakomaya FHIR platform — including the FHIR v6 upgrade
References
- FHIR implementation registry — https://confluence.hl7.org/display/FHIR/Public+Test+Servers